Server, terminal control device and terminal authentication method

ABSTRACT

Due to the mobility of mobile node devices including for example a laptop computer used on a work network and also on a home network with different home addresses, a mobile node (MN) home address and HA (home agent) address may need to be dynamically changed when using prefix communication functions and HA address discovery functions so methods for manually setting the IPsec SA security for encryption between the MN and HA are not practical in this environment. The current Mobile IPv6 protocol also has no function allowing recognition of the MN itself.  
     In the present invention may perform the following. Information on whether a prefix is distributable to a MN is held by a CA (certification authority). The server section of the HA allots prefix information to a MN approved by the CA. When the server section of the HA receives an IKE packet from the MN, the server section generates an IPsec SA after checking the prefix information in the server section. The server section allows an MN location registration request to fulfill the IPsec SA. The CA approves distribution of a prefix to the MN and verifies that the MN is genuine by generating an IPsec SA with the HA by utilizing the prefix distributed by the MN.

PRIORITY CLAIM

[0001] This application claims priority under 35 USC 119 to Japanesepatent application P2003-064329 filed Mar. 11, 2003, the entiredisclosure of which is hereby incorporated by reference.

FIELD OF THE INVENTION

[0002] The present invention relates to a server, mobile control device,and terminal authentication method. The present invention relates inparticular to a server, home agent device and terminal authenticationmethod for guaranteeing and issuing public key certifications incommunication systems using mobile IP protocol.

BACKGROUND OF THE INVENTION

[0003] The IETF (Internet Engineering Task Force) is evaluatingspecifications for Mobile IPv6 (Ref. Mobility Support in IPv6<draft-ietf-mobileip-ipv6-19.txt>, Work in Progress).

[0004] The elements comprising the Mobile IPv6 network are a mobile node(MN), a home agent (HA), and correspondent node (CN).

[0005] The MN is assigned an IP address (home address) that does notchange even if the MN moves. A link possessing a prefix identical to thehome address is called a home link. The HA manages MN locationinformation (binding cache) in locations other than the home link.

[0006] The MN acquires a Care of Address (hereafter CoA) for links otherthan the home link. The MN that is not within the home link receivesrouter reports (advertisements) sent periodically by a router within thevisited link. The MN senses movement by detecting a prefix differentfrom the home address and generates a CoA. The MN registers (stores)information linking the CoA and home address within the HA.

[0007] The MN contains a home agent address discovery function (functionfor finding the HA address) and may actively search for the IP addressof the HA. The MN first of all creates a Mobile IPv6 Home-Agents AnycastAddress from the prefix of the home link. The MN sends an ICMP HomeAgent Address Discovery Request to the address destination. This signalis received by one of the home link HA. The HA that received the signalsends an ICMP Home Agent Address Discovery Reply containing informationon the HA to the MN. The MN extracts the HA information from this signaland acquires the HA address. The MN sends a binding update for that HAaddress.

[0008] The HA receives the binding update and stores the MN locationinformation in the binding cache.

[0009] In order to function as a proxy for the MN, the HA sends aneighbor advertisement addressed to all-nodes multicast addresses of thehome link. The node that received that neighbor advertisement, storesinformation linking the MN home address and HA link layer address, inthe neighbor. cache. The HA captures the packet addressed to the homeaddress of the MN.

[0010] Mobile IPv6 contains a function to notify MN outside the homelink, of home network prefix information. For example, if the prefix ofthe home network has been changed, the HA refers (searches) the bindingcache and reports the prefix information (makes a mobile prefixadvertisement) to the MN among the registered positions. The MN may alsomake a request to the HA for prefix information (mobile prefixsolicitation).

[0011] The IP Security Protocol (IPsec) is the focus of attention as atechnology for achieving security on the IP network. This IPsec is atechnology for safely conveying IP packets by utilizing encryptiontechnology and certification technology. Mobile IPv6 is applying thisIPsec technology in the sending of location registration signals(binding updates) from the MN to the HA (Ref.draft-ietf-mobileip-mipv6-ha-ipsec-01.txt, Work in Progress).

[0012] This IPsec technology provides a security function by creating anSA (security association) among the devices using IPsec. The devicesutilizing IPsec contain a SPD (security policy database) and an SAD(security association database).

[0013] The security policy database (SPD) specifies the method forprocessing the packets. The security association database (SAD) is alist of SA (security associations) held in the devices using IPsec. TheSA is identified by a SPI (Security Parameters Index).

[0014] The method for creating the SA includes a manual setting methodand an automatic creation method. The IKE (Internet Key Exchange) is aprotocol for automatically creating and managing these SA. The IKEautomatically generates the SA by making use of a proposal exchangefunction, a function to generate a secret key, and a certificationfunction for IKE correspondent nodes.

[0015] Certification methods specified for IKE correspondent nodes arethe Pre-shared key authentication method, public key certificationmethod, digital signature authentication method, etc. The digitalsignature authentication method is highly flexible since it need notshare key information beforehand with the other communication party (orcorrespondent node). The digital signature certification method is usedby the CA (Certification Authority) for issuing public keycertifications. The format for public key certification is the specifiedin X. 509.

[0016] The CMP (Certificate Management Protocol) is a protocol forissuing and managing electronic certifications. The CMP is specified inIETF RFC2510. The CMP is utilized in transport protocols in HTTP(HyperText Transfer Protocol) and TCP (Transmission Control Protocol).

[0017] One technology proposed for localized mobility management basedon Mobile IPv6 is Hierarchial Mobile IPv6 mobility management (HMIPv6)(Ref. draft-ietf-mobileip-hmipv6-07.txt, Work in Progress). This HMIPv6contains a MAP (Mobile Anchor Point) between the HA and MN. The MNreceives a router advertisement containing MAP options from the AR(Access Router), acquires the MAP IP address, and generates a RCOA(Regional Care of Address) and LCoA (On-link CoA). The MN compatiblewith HMIPv6 registers location information in the MAP and HA. The MAPmanages the binding information of the MN RCoA and LCoA. The HA managesthe binding information of the MN home address and RCoA. The MN onlyrewrites (updates) the MAP location information when the MN has movedwithin the MAP.

[0018] The IETF is currently evaluating IPv6 Prefix Delegation Optionsfor DHCPv6 (hereafter, DHCP-PD)(draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt, Work in Progress).The DHCP-PD is a function making use of DHCP (Dynamic Host ConfigurationProtocol) to assign IPv6 prefixes (group) to sites from the addressassignment side.

[0019] The elements comprising the DHCP-PD are the delegating router andthe requesting router. The requesting router asks the delegating routerto assign an IPv6 prefix (group). The delegating router selects an IPv6prefix (group) and sends that to the requesting router. The DHCP-PD forexample, is utilized by the ISP (Internet Service Provider) whenassigning prefixes to subscribers.

[0020] In a communication system mutually connected to both a zone A andzone B, when a mobile node (MN) belonging to zone A has moved to zone B,that MN registers its location in the HA of zone A. The locationregistration signal (binding update signal) is then subjected to IPsecprocessing.

[0021] The related art has the problem that security cannot bemaintained when manually setting the SA (security association) for theHA and MN, and information about the key used in encryption has leakedout. Also, using the Mobile IPv6 prefix report (advertise) function andHA address discovery function will change the home address of the MN orHA address. The method for manually setting the SA between the MN and HAis therefore not practical during system operation. There is also nomeans for currently verifying on Mobile IP if the MN is genuine.

SUMMARY OF THE INVENTION

[0022] The present invention may provide a terminal authenticationmethod that utilizes Mobile IP technology. In particular, this inventionmay provide a procedure for authenticating terminals by linking adigital signature authentication method with a Mobile IP locationregistration procedure, and by creating and holding a SA (securityassociation) for a home address linked to the HA issuing public keycertifications.

[0023] The present invention may also to provide a system forauthenticating genuine terminals by linking a DHCP-PD delegating routerand CA, and by linking a DHCP-PD delegating router and HA, when the MNis dynamically acquiring a home address.

[0024] The present invention in particular may have the followingfeatures when a terminal x of a home network with an HA belonging tozone A, utilizes a DHCP-PD section in zone B to acquire a home networkprefix.

[0025] 1) The DHCP-PD delegating router may allot prefix information toa terminal approved by CA.

[0026] 2) The HA creates an SA for an IP address possessing a prefixallocated by that delegating router, and approves location registrationto satisfy the SA.

[0027] The present invention may also to provide an authenticationmethod for a DHCP delegating router to allot prefix information toterminals approved by the CA, when a communication device belonging tozone B possesses a HMIPv6 compatible MAP, and that communication devicereceives a binding update from the MN and starts the DHCP-PD section.

[0028] The present invention may also provide a communication method forthe HA to report prefix information to a terminal approved by CA.

[0029] More specifically:

[0030] (1) The CA may be comprised of a system for communicating with aDHCP-PD delegating router section 16 as show in FIGS. 2, 20, and 23. TheCA issues a public key certification to the terminal and allowsreporting prefix information.

[0031] (2) The terminal is comprised of a Mobile IPv6 function, an IPsecfunction, and a function to hold information required for a digitalsignature name. Information required for authenticating a digitalsignature name may be received from an external storage device. Theterminal need not be a mobile terminal.

[0032] (3) The terminal control device contains a delegating routerfunction for a DHCPv6 Prefix delegation option (hereafter, DHCP-PD). Thedelegating router function is comprised of a system for communicatingwith CA, and a system for reporting prefix information to a terminalapproved by CA.

[0033] (4) The terminal control device inquires about prefix informationto the DHCP-PD delegating router function when a request to create an SAis received from the terminal. The terminal control device comprises asystem to create an SA among terminals if the terminals utilize prefixesallotted by the delegating router function.

[0034] (5) The terminal control device may contain a storage device orsystem to hold the public key certification for a terminal. Prefixinformation may be conveyed to terminals approved by the CA.

DETAILED DESCRIPTION OF THE DRAWINGS

[0035]FIG. 1 is a concept drawing showing the structure of thecommunication network of the present invention;

[0036]FIG. 2 is block diagram of the home agent HA1;

[0037]FIG. 3 is a binding cache management table contained in HA1:

[0038]FIG. 4 is a prefix control table contained in HA1;

[0039]FIG. 5 is a flow chart of the prefix delegation processing routinecontained in the DHCP-PD section of HA1:

[0040]FIG. 6 is a flow chart of the IPsec processing routine containedin the IPsec of HA1;

[0041]FIG. 7 is a block diagram of the certification authority CA3;

[0042]FIG. 8 is a drawing of a prefix allocation control table containedin CA3;

[0043]FIG. 9 is a flow chart of the public key certification issueroutine contained in A3;

[0044]FIG. 10 is drawing showing the format of the IPv6 packet;

[0045]FIG. 11 is a drawing showing an example of a CMP message;

[0046]FIG. 12 is drawing showing the format of the DHCPv6 packet;

[0047]FIG. 13 is a drawing showing the format of an ISAKMP packet;

[0048]FIG. 14 is a drawing showing the format of an ISAKMP packet whenconfirming an identity of IKE phase 1;

[0049]FIG. 15 is an example of a binding update message;

[0050]FIG. 16 is an example of a binding acknowledgement message;

[0051]FIG. 17 is a sequence drawing 1 for location registration (bindingupdate) and authentication in the present invention;

[0052]FIG. 18 is a sequence drawing 2 for location registration (bindingupdate) and authentication in the present invention;

[0053]FIG. 19 is a concept drawing showing the structure of thecommunication network of the second embodiment;

[0054]FIG. 20 is a block diagram of the communication device 2 of thesecond embodiment;

[0055]FIG. 21 is a sequence drawing for location registration (bindingupdate) and authentication in the second embodiment;

[0056]FIG. 22 is a concept diagram showing the structure of thecommunication network of the third embodiment;

[0057]FIG. 23 is a block diagram of the communication device 2 of thethird embodiment;

[0058]FIG. 24 is a sequence drawing for location registration (bindingupdate) and authentication in the third embodiment;

[0059]FIG. 25 is a sequence drawing 1 for location registration (bindingupdate) and authentication in the fourth embodiment;

[0060]FIG. 26 is a sequence drawing 2 for location registration (bindingupdate) and authentication in the fourth embodiment; and

[0061]FIG. 27 is a sequence drawing 3 for location registration (bindingupdate) and authentication in the fourth embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS First Embodiment

[0062] The first embodiment of the present invention is described nextwhile referring to the accompanying drawings. In this embodiment, the HAis equivalent to a terminal control device.

[0063] The MN authentication method and location registration methodused when the Mobile IPv6 compatible mobile node (MN) is in a network(hereafter, visited network) other than the home link (hereafter, homenetwork) is described in detail.

[0064]FIG. 1 shows the structure of the communication network of thepresent invention. The communication network is comprised of a homenetwork 8 for MN4, an IP network 7 and a visited network 5 (5 a, 5 b).In this embodiment, the home network 8, the IP network 7 and the visitednetwork 5 are IPv6 networks. The MN4 is a mobile node (MN) compatiblewith Mobile IPv6. The information appliance terminal 9 contains MNfunctions compatible with Mobile IPv6. The visited network 5 and IPnetwork 7, and the IP network 7 and home network 8 are connected byrouter or a gateway device. The visited network 5 and home network 8 mayalso be directly connected by a router or a gateway device.

[0065] The home network 8 contains a home agent HA1. The HA1 is a homeagent (HA) compatible with Mobile IPv6. The HA1 manages MN locationinformation other than in the home network 8.

[0066] The visited network 5 (5 a, 5 b) is comprised of a communicationdevice 2 (2 a, 2 b) and a router 6 (6 a, 6 b, 6 c, 6 d). Thecommunication device 2 is comprised of an interface with a router 6, andan interface with an IP network 7. The router 6 contains a deviceauthentication function.

[0067] Instead of the device authentication function, the router 6 mayutilize a system for communicating with a server possessing a deviceauthentication function.

[0068] The IP network 7 contains the CA3. The home network 8 or thevisited network 5 may also contain the CA3.

[0069]FIG. 2 shows the structure of the HA1 installed in the homenetwork 8 of MN4. The HA1 is comprised of a server section 11, (11 a, 11b) , a server section 12, and an interface section (IF) 19 (19 a, 19 b,19 m, 19 n) containing a line 18 (18 a, 18 b, 18 m, 18 n) and, a switchsection 17 (17 a, 17 b)

[0070] The server section 11 mainly contains a packet transmit-receiveprocessor 13, an IPsec processor 14, and a mobile IP processor 15. Thepacket transmit-receive processor 13 contains a function to transmit orreceive data packets. The IPsec processor 14 contains mainly an SPD, SADand an IPsec processing routine 70. The IPsec processor 14 authenticatespackets and performs encoding. The IPsec processor 14 acquires serversection 11 public key certification from the CA3. The mobile IPprocessor 15 contains a Mobile IPv6 for the home agent (HA) function.The mobile IP processor 15 contains a binding cache management table310.

[0071]FIG. 3 shows the table structure of the binding cache managementtable 310. The binding cache management table 310 stores at least a Careof Address (CoA) 312 acquired by the MN in the visited network for theMN home address 311, and a Lifetime 313 showing the effective period ofthe binding cache.

[0072] The server section 12 contains a packet transmit-receiveprocessor 13 and a DHCP PD section 16.

[0073] The DHCP PD section 16 contains a DHCP-PD delegating routerfunction. It also contains mainly a prefix control table 320, a prefixdelegation processing routine 60, and a table linking the IA_PD foridentifying the DHCP-PD and an MN identifier.

[0074]FIG. 4 shows the structure of the prefix control table 320. Thisprefix control table 320 in DHCP PD Section 16 stores at least anIAID322 showing the prefix (group), an allocated prefix 323, and alifetime 324 of the prefix, and shows the corresponding relation withthe DHCP Client identifier 321. The DHCP-PD section of the server 12 ismounted in HA1, however a DHCP-PD section may be mounted in a serverseparate from the HA1.

[0075]FIG. 7 shows the structure of the certification authority (CA) 3installed in the IP network 7. The CA3 is comprised a CPU31, a memory32, and an interface section (IF) 33 containing the line 34, and a bus35 connecting these components.

[0076] The memory 32 is comprised of at least a prefix allocationcontrol table 330 and, a public key certification issue routine 80, anda certifying information storage table.

[0077]FIG. 8 shows the table structure of the prefix allocation controltable 330. The prefix allocation control table 330 stores a Prefix issueOK flag 332 showing whether or not permission to issue a prefix wasissued to the identifier (ID) 331 of the terminal.

[0078] The sequence for location registration and authentication of MN4in the network 5 b shown in FIG. 1, is described according to thesequence shown in FIG. 17 and FIG. 18. In this embodiment, the MN4contains a system to load the identifier and secret key and public keyfrom a storage device typically a Secure Multimedia Card (SMMC), etc.The MN4 further contains a DHCP-PD requesting router function.

[0079] When power is turned on, the MN4 receives (101) a routeradvertisement from the router 6 c belonging to the network 5 b. The MN4searches the M bit of the router advertisement and decides on a methodfor acquiring the CoA (Care of Address). If the M bit is 1, then MNacquires the CoA using the automated structure of the IPv6 statefulladdress. If the Mbit has not been set, then the Mbit creates a CoA (102)utilizing the automated structure of the IPv6 stateless address.

[0080] The MN4 next sends a device authentication request to the router6 c (103). The router 6 c authenticates the device, using the device IDas a search (or retrieval) key. The router 6 c sends (104) a deviceauthentication response including the authentication results to MN4. AMAC address for example is utilized as the device ID.

[0081] When device authentication ends correctly, the MN4 loads the MN4identifier and secret key and public key from a storage device such asthe SMMC. The MN4 identifier specifies for example, a FQDN (fullyqualified domain name) or a distinguished name of X.500.

[0082] The MN4 sends a public key certification issue request containingan MN4 public key and identifier to the CA3 (105). A CMP (CertificateManagement Protocol) is utilized for sending and receiving the publickey certification.

[0083]FIG. 11 shows a packet format S1 containing a CMP message.

[0084]FIG. 10 shows the format of an IPv6 packet.

[0085] The CMP message S1 is stored in data section 43B within thepayload 43 of the IPv6 packet.

[0086] The CA3 receives the request and starts the public keycertification issue routine 80.

[0087]FIG. 9 shows the public key certification issue routine 80. TheCA3 confirms whether a certification can be issued to MN4 using the MN4identifier (81). If a certification can be issued then the CA3 issues apublic key certification for MN4. The CA3 next creates a new entry forMN4 in the prefix allocation control table 330, and sets up a prefixissue OK flag (82, 106). The CA3 sends a public key issue requestresponse containing a public key certification for MN4 and a public keyfor CN3, and ends this routine (83, 107).

[0088] When the certification cannot be issued in step 81, or in step 82when the certification cannot be issued for a public key for MN4, theCA3 issues a certification issue request response (84) to notify the MN4of the error and ends this routine.

[0089] The server section 11 of HA1 holds an identifier ,a HA secret keyand a HA public key. This procedure is similar to the procedure used bythe MN which has its own MN secret and MN public key. The server section11 acquires the public key certification from the CA3 (for serversection 11) (183).

[0090] After acquiring the MN's public key certification, the MN4 startsthe prefix request process and acquires a home prefix.

[0091] To find a DHCP server with a prefix that can be allocated, theMN4 sends a DHCP solicit message to theAll_DHCP_Relay_Agents_and_Servers address (108). This solicit messageincludes a DHCP client identifier (client identifier option) and IA_PDoption. An IAID showing a group (IA_PD) applying a prefix within the MNis set in the IA_PD options.

[0092]FIG. 12 shows an S2 packet format containing a DHCPv6 message. TheDHCPv6 is an application protocol using UDP/IP in the transport layer.The DHCP message S2 is stored in the data section 43B of payload 43 ofthe IPv6 packet. The DHCP message specifies the value in themessage-type field 51. The option parameter of the DHCP message is setin the Options field 53.

[0093] Here, the server section 12 for HA1 receives the DHCP solicitmessage (108). The server section 12 for HA1 then starts up the prefixdelegation processing routine 60.

[0094]FIG. 5 shows the prefix delegation processing routine 60.

[0095] The server section 12 loads the IAID from the IA_PD options ofthe DHCP solicit message, and decides (61) if a prefix can be allocatedto the IAID. If a prefix can be allocated then the server section 12designates an IA_PD from the IAID containing that DHCP solicit message.The server section 12 searches the table linking the MN4 identifier andIA_PD, using the IA_PD as a search (retrieval) key, and decides the MN4identifier. The server section 12 sends a request (62, 109) containingMN4 identifiers to the CA3.

[0096] When an inquiry is received, the CA3 searches the prefixallocation control table 330 using the NN4 identifier as a search key(110).

[0097] The CA3 searches for the MN4 entry generated in step 106. The CA3confirms that a prefix issue OK flag is set for the applicable entry,and sends a response showing prefix allocation is allowed, to the server12 (63, 111).

[0098] When a response is received, the server section 12 searches theDHCP client identifier with the IAID contained in that DHCP solicitmessage, and the prefix control table 320. When the applicable entry isnot present in the prefix control table 320, the server section 12generates a new entry in the prefix control table 320, and stores anIAID322 and DHCP client identifier 321 that are contained in that DHCPsolicit message. The server section 12 then sends a DHCP advertisemessage to the MN4 (64, 112). This advertise message contains anidentifier for server section 12 (server identifier option), anidentifier for MN4 (client identifier option), and the IA_PD optionsreceived in step 108. The advertise message from the server section 12may also include IPv6 prefix information for allocation.

[0099] When the server 12 cannot allocate the IPv6 prefix to the IAIDinstep 61, or when the CA3 does not allow allocation of the prefix instep 63, then the-server 12 sends an advertise message containing astatus code option to the MN4 showing the prefix cannot be allocated andends this routine (67).

[0100] When allocation (or distribution) of the prefix is approved, theMN4 sends a DHCP request message containing IA_PD options to the serversection 12 and requests IPv6 prefix information (113).

[0101] When the advertise message received in step 112 contains an IPv6prefix message, the request message contains the prefix that the MN4needs to use.

[0102] Here, returning to FIG. 5, the description of the prefixdelegation processing routine 60 continues.

[0103] When the DHCP request message is received (65), the serversection 12 loads the IAID and specifies the IPv6 prefix for allocation.When the request message contains IPv6 prefix information, then theprefix needed for use by MN4 is approved.

[0104] The server section 12 next searches the prefix control table 320with the IAID and DHCP client identifier contained in the DHCP requestmessage. The server section 12 detects and entry generated in step 64,and stores the IPv6 prefix for distribution and the prefix lifetime inthe applicable entries. The server section 12 sends a DHCP reply messagecontaining the prefix information to MN4 (66, 114), and ends thisroutine.

[0105] When a prefix for allocation to MN4 could not be specified instep 65, or when there was no applicable entry in the prefix controltable 320 in step 66, then the server section 12 sends a DHCP replymessage (68) to MN4 to report the error and ends this routine.

[0106] The MN4 extracts IPv6 prefix information from that DHCP replymessage. The MN4 creates a home address from the prefix information andthe MN4 interface identifier.

[0107] The MN4 next specifies the HA address using the HA (home agent)address discovery function. The MN4 sends the Home Agent AddressDiscovery Request (116) to the Mobile IPv6 Home-Agents Anycast Addressset in the home network prefix received in step 114.

[0108] One of the HAs which process the same prefix as the Mobile IPv6Home-Agents Anycast Address may receive the Home Agent Address DiscoveryRequest.

[0109] The server section 11 a of HA1 receives the Home Agent AddressDiscovery Request. The server section 11 a sends the Home Agent AddressDiscovery Reply to the MN4 (117).

[0110] The MN4 receives the Home Agent Address Discovery Reply andacquires the HA address (address of server section 11 a) (118).

[0111] The MN4 next utilizes an IKE to create an IPsec SA for usebetween the server section 11 a and MN4.

[0112] In IKE phase1, an ISAKMP SA is established between the MN4 andserver section 11 a. The ISAKMP SA is a control channel for the IKE. TheMN4 proposes ISAKMP SA parameters (121) utilizing the SA payload in theserver section 11 a.

[0113]FIG. 13 shows the ISAKMP packet format S3. The packet format usedby IKE is specified in the ISAKMP protocol. The IKE transport protocolis UDP/IP.

[0114] The ISAKMP packet S3 is stored in the data section 43B of payload43 of the IPv6 packet. The ISAKMP packet S3 is comprised of an ISAKMPheader 55 and one or more payloads 56. The payload 56 contains forexample, an SA payload to transport the proposed SA, an identificationpayload to exchange the ID information, and a signature payload to sendthe digital signature, etc.

[0115] The server section 11 a selects an acceptable proposal from theSA payload received in step 121 and returns it to the MN4 (122).

[0116] The MN4 and server section 11 a next exchange Diffe-Hellmanpublic values and random numbers obtained per Nonce (123, 124) andgenerate a secret key.

[0117] The MN4 and server section 11 a next exchange ID information forverifying a personal identity. In this embodiment, the signal sent whenconfirming if the identity attribute is the actual person is defined asthe personal identity check signal. FIG. 14 shows the ISAKMP packetformat S4 utilized in checking the personal identity for IKE phase 1.The ISAKMP packet S4 contains the identification payload 56A, signaturepayload 56B and the certificate payload 56C.

[0118] The MN4 sends (125) the ISAKMP packet utilized in the personalidentity check to the server section 11 a. The identification payload56A of this ISAKMP packet 125 includes the home address generated by MN4in step 115. The MN4 calculates the hash value, executes the digitalsignature utilizing the MN4 public key in that hash value, and sets itin the signature payload 56B. The certificate payload 56C includes MN4public key certification that CA3 issued.

[0119] The server section 11 a extracts the MN4 digital signature fromthe signature payload 56B of packet 125. The server section 11 a thendecodes the digital signature using the MN4 public key. The MN4 publickey is acquired from the certificate payload 56C of packet 125.

[0120] The server section 11 a confirms the personal identity of thepacket sender MN4 by comparing the hash value calculated from thereceived packet 125 and the decoded value of that digital signature.

[0121] The server section 11 a next extracts the MN4 home address fromthe identification payload of packet 125. The server section 11 a sendsan inquiry containing the home prefix to the server section 12 (126).The server section 12 searches the prefix control table 320 using theprefix contained in that request 126 as a search key. If an applicableentry is present in the prefix control table 320, then assigning of theprefix is complete (127). The server section 12 sends a reply to theserver section 11 a notifying that prefix allocation is complete (128).

[0122] If allocating of the prefix is complete, the server section 11 acontinues the processing of IKE phase 1. The server section 11 aexecutes the digital signature using the public key of server section 11a in the hash value. The server section 11 a sends the ISAKMP packetcontaining the digital signature to MN4 (129). The IP address of serversection 11 a is set in the identification payload of the ISAKMP packet129. This ISAKMP packet may be included in the public key certificationof server section 11 a. The public key certification of server section11 a was issued in step 183. Alternatively the public key certificationof server section 11 a may be issued in step 181 and 182 of FIG.29, andin this case the step 183 is needless (FIG. 28). The MN4 receives thepacket 129 and confirms if the other party in the IKE communicationusing the public key of server section 11 a is genuine. The MN4 acquiresthe server section 11 a public key from the public key certification inpacket 129 or acquires it from CA3.

[0123] The ISAKMP SA has now been established between MN4 and the serversection 11 a.

[0124] The IPsec SA is next created in IKE phase 2, for MN4 and serversection 11 a. This IPsec SA is utilized when IPsec processing andforwarding the packets between the MN4 and server section 11 a. Thepayload for ISAKMP packets sent and received in IKE phase 2 is encodedusing the ISAKMP SA established in IKE phase 1.

[0125] The MN4 sends an ISAKMP packet to the server section 111 a. An SApayload containing the IPsec SA proposal, a Nonce payload, and a hashpayload were set in this ISAKMP packet (130). The server section 11 athen sends to the MN4, the ISAKMP packet in which are set the IPsec SApayload containing the accepted IPsec proposal, the Nonce payload, andthe hash payload (131).

[0126] The MN4 sends the ISAKMP packet containing the hash payload tothe server section 11 a (132). The server section 11 a receives thispacket (132) and confirms that MN4 has received the packet 131. Theabove process generates two IPsec SA (the IPsec to the server section 11a from MN4, and the IPsec SA to the MN4 from the server section 11 a).The server section 11 a and the MN4 store the IPsec SA (SPI, MN4 homeaddress, and server section 11 a address, etc.) in the respective SAD.

[0127] The MN4 sends a binding update adapted for the SA generated inIKE phase 2 to the server section 11 a (133). The MN4 temporarily storesthe address of server section 11 a in the binding update list controltable (134).

[0128]FIG. 15 shows the binding update message format S11 compatiblewith IPsec. The IPv6 destination options header 401, IPsec header (AHheader or ESP header) 402, and the IPv6 mobility header 403 are storedin the IPv6 packet extension header 42.

[0129] The MN4 stores the following values in the binding update sent tothe server section 11 a. The CoA of the MN4 is set in the source address41a of the IPv6 packet header. The home address that the MN4 generatedin step 115 is set in the home address field of the IPv6 DestinationOptions Header 401.

[0130] The server section 11 a receives this binding update 133 andstarts the IPsec processing routine.

[0131]FIG. 6 shows the IPsec processing routine 70. The IPv6 DestinationOptions Header 401 is processed first (71). More specifically, theDestination Options Header value (home address) and the source addressvalue (CoA) are exchanged with each other.

[0132] The server section 11 a next searches the SAD for the type ofIPsec (AH or ESP), SPI value, and destination address, and specifies theIPsec SA. When the received packet has been encoded, the server section11 a first decodes the received packet and checks that it matches thespecified IPsec SA (72). The server section 11 a next searches the SPD,and checks whether the (now) reconstructed packet can be accepted (73).

[0133] If the packet can be accepted, then the IPsec processor 14 ofserver section 11 a sends the reconstructed packet to the mobile IPprocessor 15.

[0134] The mobile IP processor 15 registers the MN4 location (makes abinding update) (74).

[0135] The mobile IP processor 15 searches the binding cache managementtable 310 using the MN4 home address as a search (retrieval) key. Ifthere is no MN4 entry in that binding cache management table 310, thenan MN4 entry is added to the binding cache management table 310 (135).The MN4 sets the CoA acquired in the visited network 5 b, into the Careof Address 312 entry.

[0136] If the processing in step 72 and step 73 did not end correctly,then the server section 11 a discards the received packet and ends thisroutine (78).

[0137] The mobile IP processor 15 sends the packet to the IPsecprocessor 14 for sending a binding acknowledgement adapted to IPsec, tothe MN4. The IPsec processor 14 searches the SPD and investigates thepacket security policy (75). When found that the packet is usable withIPsec, a matching SA is detected from the SAD. The IPsec processor 14adds a routing header 404 to this packet and applies IPsec (76). Theserver section 11 a next interchanges the routing header value and thedestination address value. The server section 11 sends a bindingacknowledgement subjected to IPsec processing, to MN4 (77, 136) and thenends this routine.

[0138]FIG. 16 shows the format S12 of a binding acknowledgement messagesubjected to IPsec. The IPv6 routing header 404, the IPsec header (AHHeader or ESP header) 402, and the IPv6 mobility header 403 are storedin the IPv6 packet extension header 42. The server section 11 a storesthe following values in the binding acknowledgment sent to the MN4. TheCoA of MN4 is stored in the destination address 41b of the IPv6 packetheader. The MN4 home address is stored in the home address field of theIPv6 routing header 404.

[0139] When the binding acknowledgement is received, the MN4 searchesthe SAD and specifies an SA. When the received packet has been encoded,the received packet is checked after decoding, to find if it matches theSA. The SPD is also searched and a check made to determine if thereconstructed packet can be accepted. If acceptable, the MN4 registersthe entry temporarily stored in step 134, into the binding update listcontrol table (137).

[0140] Here, the MN4 may register the identification information (forexample FQDN) and information matching the home address acquired in step115, into the home network 8, the visited network 5, or the locationinformation control device (for example a DNS server device) belongingto the IP network 7.

[0141] The information appliance terminal 9 is comprised of a MobileIPv6 function and a DHCP-PD requesting router function. Anauthentication method can be used with the information applianceterminal 9 if a public key certification is acquired from the CA3.

[0142] The first embodiment of the present invention can thereforeprovide an authentication method for verifying the authenticity of theIPv6 terminal, by linking a digital signature authentication method witha Mobile IP location registration (binding update) procedure, and by theHA creating and holding an SA for the home address linked to the publickey certification.

[0143] The MN4 and HA1 server section 11 hold a public key certificationissued by the CA3. The HA1 server section 12 and the MN4 contain aDHCP-PD section. By linking the CA3 and the HA1 server section 12, theHA1 can give a prefix notification to the MN4 to whom prefix allocationwas approved by CA3. The HA1 server section 11 can further provide anauthentication method for verifying the MN is genuine by generating anIPsec SA among the MN4 home prefix for the prefix that has beenallocated by the server section 12 already.

Second Embodiment

[0144] The second embodiment of the present invention is described nextwhile referring to the accompanying drawings.

[0145]FIG. 19 shows the structure of the communication network of thesecond embodiment of the present invention. The second embodiment ischaracterized in that the communication device 2 contains a DHCP-PDrequesting router function. In the example of the second embodiment, theIP network 7 contains an authentication server 10. The authenticationserver 10 controls information (ID, passwords, etc,) required forauthorizing access to the home network.

[0146]FIG. 20 shows the structure of the communication device 2 of thesecond embodiment of the present invention. The communication device 2is comprised of a CPU21, a memory 22, and an interface section (IF) 23(23 a, 23 b) containing a line 24 (24 a, 24 b), and a bus 25 connectingthese components.

[0147] The memory 22 is comprised mainly of a DHCP-PD section 26containing a DHCP-PD requesting router function, and an authenticationprocessor 27 for authorizing access to the home network 8.

[0148]FIG. 21 shows the sequence for location registration (bindingupdate) and authentication of MN4 in the second embodiment of thepresent invention.

[0149] The first embodiment and the second embodiment differ in theinstallation locations for the DHCP-PD requesting router function. Thecommunication device 2 (GW2) of the second embodiment contains a DHCP-PDrequesting router function, and sends and receives DHCP-PD messages.

[0150] The process from step 101 to step 107 is the same as the firstembodiment.

[0151] Hereafter, the process from step 141 onwards is described.

[0152] When a packet is received from the MN4, the GW2 requests that theMN4 send authentication information (141). The MN4 sends anauthentication request containing an ID and password (142). The GW2 bsends a DHCP solicit containing an IAID (143).

[0153] The server section 12 receives that DHCP solicit and specifies anIA_PD from the IAID. The server section 12 searches the table ofcorresponding MN4 identifiers and IA_PD using the IA_PD as a search(retrieval) key, and decides on an MN4 identifier.

[0154] The process from step 144 to step 146 is the same as steps 109 tostep 111 in the first embodiment.

[0155] When the reply 146 is received, the server section 12 sends aDHCP Advertise (notification) to the GW2 b (147). Hereafter, theprocessing from step 148 to step 149 for the server section 12 is thesame as in the first embodiment.

[0156] When the DHCP reply 149 containing the prefix information isreceived, the GW2 b sends an authentication reply containing prefixinformation to the MN4 (150). Hereafter, the MN authenticationprocessing and the location registration (binding update) processing isthe same as from step 115 to step 137 in the first embodiment.

[0157] The second embodiment of the present invention can thereforeprovide an authentication method for verifying the authenticity of IPv6terminals not containing a DHCP-PD section, by linking a digitalsignature authentication method with a mobile IP location registration(binding update) procedure, even in cases where the communication device2 is equipped with a DHCP-PD requesting router function.

[0158] The second embodiment can also provide a highly safecommunication service by providing a function for authorizing access toHA from the communication device 2.

Third Embodiment

[0159] The third embodiment of the present invention is described nextwhile referring to the accompanying drawings.

[0160]FIG. 22 shows the structure of the communication network of thethird embodiment of the present invention. In addition to the functionsof the second embodiment, the third embodiment is characterized bypossessing HMIPv6 MAP functions. In the third embodiment, the MN4 is amobile terminal compatible with HMIPv6.

[0161]FIG. 23 shows the structure of the communication device 2 of thethird embodiment. The memory 22 of the communication device 2 containsan HMIPv6 processor 29 in addition to the functions shown in the secondembodiment. The HMIPv6 processor 29 provides the HMIPv6 compatible MAPfunctions. The HMIPv6 processor 29 contains a binding cache managementtable for holding information linking the RCoA and LCoA.

[0162] The sequence for location registration (binding update) andauthorization for MN4 in the network 5 shown in FIG. 22 are describedaccording to the sequence shown in FIG. 24.

[0163] The MN4 receives a router notification (router advertisement)containing MAP options from the router (AR: Access Router) 6 c belongingto the network 5 b (161). The MN4 specifies the communication device(hereafter MAP) using the router advertisement information 161 andgenerates an RCoA and LCoA (162).

[0164] The process from step 103 to step 107 is the same as in the firstembodiment.

[0165] When the MN4 receives the public key certification from the CA3,it sends a binding update (location registration signal) to the MAP2 b(163).

[0166] In the third embodiment, the MAP2 b utilizes the receiving of thebinding update (location registration signal) to initiate authenticationprocessing. The process hereafter from step 141 to step 150 is the sameas the second embodiment.

[0167] When the processing up to step 150 ends correctly, the MAP2 bstores information linking the RCoA and LCoA of MN4, into the bindingcache management table of the HMIPv6 processor 29. The MAP2 b sends thebinding acknowledgement to the MN4 (164).

[0168] The MN authorization process and location registration (bindingupdate) process hereafter are the same as from step 115 to step 137 ofthe first embodiment. The third embodiment of the present invention cantherefore provide an authentication method for verifying theauthenticity of IPv6 terminals not containing a DHCP-PD section, bylinking a digital signature authentication method with a mobile IPlocation registration (binding update) procedure, even in cases wherethe communication device 2 is equipped with a HMIPv6 function.

[0169] The third embodiment can also provide a communication servicewith higher safety by the communication device initiating the accessauthentication processing for the home network when the HMIPv6 controlsignal is received.

Fourth Embodiment

[0170] The fourth embodiment of the present invention is described nextwhile referring to the accompanying drawings. The structure of thecommunication network in the fourth embodiment is the same as in thefirst embodiment.

[0171] The fourth embodiment is characterized in that the server section11 of the HA1 comprises a system to allocate the prefix to MN approvedby the CA3, and in containing a MN4 public key certification controltable. Information on the identification payload contained in the ISAKMPpacket of IPsec phase 1 and information linked to the public keycertifications are stored in the public key certification control table.

[0172] In the fourth embodiment, the HA1 and the MN need not contain aDHCP-PD section. The HA of the MN4 is the server section 11 a.

[0173] After the MN4 in the network 5 b shown in FIG. 1, has completedlocation registration (binding update) in the server section 11 a, thesequence from the HA1 server section 11 a notifying the MN4 of theprefix, to the MN4 once again completing location registration (bindingupdate) is described while following the sequence shown from FIG. 25through FIG. 27.

[0174] The sequence from step 101 to step 107 is the same as in thefirst embodiment.

[0175] The MN4 next creates an IPsec SA in the server section 11 a.

[0176] The sequence from step 121 through step 125 is the same as in thefirst embodiment. The MN4 sends to the server section 11 a, an ISAKMPpacket 125 containing an identification payload set with the M4 homeaddress, and with a certificate payload set with the MN4 public keycertification.

[0177] The server section 11 a loads the certificate payload andidentification payload information from the packet 125, and adds the MN4entry to the public key certification control table (171). If an MN4entry is already present, then the applicable entry is rewritten(updated).

[0178] The sequence from step 129 to step 132 is the same as in thefirst embodiment.

[0179] The MN4 carries out location registration (binding update)utilizing an IPsec SA generated by MN4 and the server section 11 a. Thelocation registration (binding update) is the same as the firstembodiment (from step 133 to 137).

[0180] When the server section 11 a is for example changing its ownprefix, the MN4 current performing the binding update is notified of theprefix by the server section 11 a.

[0181] The server section 11 a first searches the binding cachemanagement table 310 and then detects the MN4 entry generated in step135. The server section 11 a next searches the public key certificationcontrol table using the MN4 home address as a search (retrieval) key andloads the MN4 public key certification made in step 171.

[0182] The server section 11 a specifies the MN4 identifier from thepublic key certification, and sends an inquiry along with this MN4identifier to the CA3 (172, 173).

[0183] When this inquiry is received, the CA3 searches the prefixallocation control table 330 using the MN4 identifier as a search(retrieval) key.

[0184] The CA3 detects the MN4 entry created in step 106. The CA3confirms that an applicable entry is set in the prefix issue OK flag(174). The CA3 sends a reply to the server section 11 a showing a prefixcan be allocated (175).

[0185] When the reply is received, the server section 11 a sends amobile prefix advertisement to report the prefix information to the MN4(176). The server section 11 a applies the IPsec SA generated in steps130 to 132, in the mobile prefix advertisement message.

[0186] The MN4 loads the prefix from the mobile prefix advertisement.The MN4 detects changes in the home prefix, and generates a homeaddress. The process from creating the home address to completion oflocation registration (binding update) is the same as step 115 through125 in the first embodiment (step 129 through step 137).

[0187] The fourth embodiment of the present invention is thereforecapable of notifying the MN4 of the prefix information, by linking HA1and CA3 after confirming the MN is genuine.

[0188] As clearly shown by the above embodiments, the present inventionprovides an authentication method for verifying that the IPv6 terminalis genuine by linking a digital signature authentication method with aMobile IP location registration (binding update) procedure.

[0189] In particular, an authentication method can be provided forverifying the terminal x is genuine when performing Mobile IP bindingupdates (location registration) with a terminal x an HA belonging tozone A as a home network in zone B, with the method comprising a systemfor a DHCP-PD delegating router function belonging to zone A todistribute a prefix to the terminal X belonging to zone B; and furthercomprising: 1) a system for inquiring whether a DHCP-PD delegatingrouter function can allocate a prefix to CA, 2) a system for inquiringwhether the HA contains prefix information in the DHCP-PD delegatingrouter function, 3) a system for acquiring a terminal x public key fromCA or terminal x when the HA is creating IPsec SA with the terminal x,4) a system for the HA to approve only location registration (bindingupdate) subjected to the IPsec generated above in 3).

[0190] The above described authentication method for verifying aterminal x not comprising a DHCP-PD section, can be provided if acommunication device mutually connected to both zone A and zone Bcontains a DHCP-PD requesting router function and a function authorizingzone A access. Further, a communication service with a high degree ofsafety can be provided since the communication device allows onlyauthenticated terminals x to have access to the HA.

[0191] Also, if the communication device mutually connected to both zoneA and zone B contains a MAP function for HMIPv6, then the communicationdevice can use the HMIPv6 control signal as a trigger to initiate accessauthorization processing for zone A.

[0192] Further, if the HA1 contains a system for communicating with CA3and a system for holding MN4 public key certification, then prefixinformation can be reported to the MN4, after the HA1 verifies the MN4is authentic and reports this to CA3.

What is claimed is:
 1. A server device comprising: a processor forissuing and guaranteeing public key certification; a memory for holdinginformation on prefix allocation allow/prohibit information of aterminal device; and a communications interface for receiving a publickey issue certification request from said terminal device and rewritingsaid prefix allocation allow/prohibit information, and said processorstructured to run a routine wherein public key certification issuerequest is received from said terminal device, a public keycertification of said terminal device is issued by the server device;said prefix allocation allow/prohibit information is rewritten by theserver device, and said certification is sent to said terminal devicefrom the server device.
 2. A server device according to claim 1, furthercomprising: said processor structured to run a routine wherein thecommunications interface communicates with an information processingdevice containing a prefix allocation section, and wherein an inquiry onwhether prefix allocation is allowed or prohibited is received from saidinformation processing device, said information terminal device prefixallocation allow/prohibit information is searched, and allow/prohibitinformation acquired is sent to said information processing device fromsaid server device to authorize or deny the prefix allocation.
 3. Aserver device according to claim 1, wherein the communications interfacecommunicates with a terminal control device for managing the terminaldevice and for managing location information of the terminal device,said processor is structured to run a routine wherein an inquiry onwhether prefix allocation is allowed or prohibited is received from saidterminal control device, said prefix allocation allow/prohibitinformation is searched by the server, and the information acquired issent to said terminal control device from the server device.
 4. Aterminal control device comprising: a connection for communication witha server device containing a function to issue and guarantee public keycertification, and prefix allocation allow/prohibit information; atransceiver for acquiring public key certification from said serverdevice; and a routine to maintain security by utilizing IPsectechnology, and a storage to store a terminal device locationinformation, wherein information confirming the identity of saidterminal is received from said terminal device, and a terminal devicepublic key certification is acquired.
 5. A terminal control deviceaccording to claim 4, further comprising: an information processingdevice having a prefix allocation function; wherein informationconfirming the identity of said terminal is received from said terminaldevice, an inquiry for prefix information is made to said informationprocessor device, and a reply to the inquiry that indicative of thatsaid prefix was allocated is made from said information processordevice, then a signal reply to the information confirming said identityof the terminal is sent to said terminal device from the transceiver. 6.A terminal control device according to claim 4, wherein a locationregistration request or binding update request is received from saidterminal device, and security information of said terminal device isloaded, and if said request matches said security information, thenlocation registration or binding update of said terminal device isperformed in the terminal control device.
 7. A terminal control deviceaccording to claim 4, wherein information allowing prefix allocation forsaid terminal device is loaded from said server device, and if saidserver device approves allocation of a prefix to said terminal device,then the prefix information is reported to said terminal device.
 8. Aterminal authentication method for a communication system containing aninformation processor device with a prefix allocation function, and aserver device containing a processor and memory to guarantee and issuepublic key certification, and a visited network and a terminal devicecapable of connecting to said visited network, and a home network whichis associated with the terminal device, and which is mutually connectedwith said visited network, and a terminal control device connected tosaid home network via said visited network, wherein said server deviceissues a public key certification to said terminal device and rewritesprefix allocation information for said terminal device; said informationprocessor device receives a prefix allocation request from said terminaldevice, and makes an inquiry for prefix allocation allow/prohibitinformation to said server device, and allocates prefix information tosaid terminal device when allocation of the prefix is approved; saidterminal control device receives information confirming the identity ofthe terminal device from said terminal device, and sends prefixinformation of said terminal device to said information processordevice; and said information processor device establishes a securityassociation between the terminal device to which said prefix informationis issued and said terminal control device.
 9. A terminal authenticationmethod according to claim 8, wherein a communication device mutuallyconnected to a home network and a visited network sends a prefixallocation request to said information processor device.
 10. A terminalauthentication method according to claim 9, wherein said terminalcontrol device receives a location registration request from saidterminal device, loads said security association, and approves locationregistration of said terminal device when said location registrationrequest fulfills said security association.
 11. A terminalauthentication method according to claim 8, wherein said terminalcontrol device is comprised of communication interface for communicatingwith said server device, and storage device for storing public keycertification information for a terminal device; and said informationprocessor device sends prefix information to a terminal device approvedby said server device.
 12. A combination method for authentication andlocation registration of a terminal located in a visited networkcomprising: powering on a terminal; sending a router advertisement tothe terminal from a visited network router; creating a care of address(CoA) in the terminal; sending a device authentication request to thevisited network router from the terminal; sending a public keycertification issue request with a public key of the terminal and aterminal ID to a calling authority server (CA) over an IP protocolnetwork; issuing a public key certification issue response from thecalling authority server (CA) compatible with IPv6 protocol; sending aDHCP solicit message from the terminal to a home agent server (HA)compatible with IPv6 protocol wherein the home agent server (HA) islinked to the calling authority server and checks with the callingauthority server (CA) to allow prefix allocation; responding to theterminal with a DHCP advertise message included in an IPv6 protocolpayload; sending a DHCP request to the home agent server from theterminal; sending a DHCP reply to the terminal with prefix delegation;creating a home address in the terminal; sending a home agent addressdiscover request to the home agent server; responding with a home agentaddress discovery reply from the home agent server to the terminal;aquiring the home agent server home address in the in terminal;establishing a IPsec security association (SA), and digital signaturevia IKE (internet key exchange) and a secure communication channel usingphase I and II IPsec ISAKMP protocols between the terminal and a homeagent server which is linked to the calling authority server (CA) andwhich located in a home area; making a location binding update in theterminal using the IPsec security association (SA); thereby providing anauthentication method for verifying a terminal authenticity by linking adigital signature method with a location binding update method.
 13. Themethod of claim 12: wherein the terminal is an IPv6 compatible terminalwith a DHCP requesting function.
 14. The method of claim 12 wherein: adevice authentication server is included in the IP network forcontrolling ID information required to access the home agent router; acommunication gateway is included in the IP network comprising a DHCP-PDrequesting router function which handles the DHCP communications to theterminal from the home agent server and the calling authority server(CA); wherein the terminal does not have to have a DHCP function and sothat terminals without DHCP functions can be authenticated and theirlocation can be updated according to the method.
 15. The method of claim12: wherein a HMIPv6 Mobile Anchor Point (MAP) function is included inthe method in a communication device having a HMIPv6 processor andwherein the terminal is compatible with HMIPv6; wherein the HMIPv6processor contains a binding cache management table for holdinginformation linking a regional care of address (RCoA) and a local careof address (LCoa); and wherein instead of the terminal sending thesending a DHCP request instead the HMIPv6 Mobile Anchor Point (MAP)function is included in the method in a communication device performsDCHP communications so that the terminal does not have to be a DHCPcompatible terminal.
 16. A combination method for authentication andlocation registration of a terminal located in a visited networkcomprising: powering on a terminal; sending a router advertisement tothe terminal from a visited network router; creating a care of address(CoA) in the terminal; sending a device authentication request to thevisited network router; sending a public key certification issue requestwith a public key and a terminal ID to a calling authority server overan IP protocol network; issuing a public key certification issueresponse from the calling authority server (CA) compatible with IPv6protocol; establishing a IPsec security association (SA), and digitalsignature via IKE (internet key exchange) and a secure communicationchannel using phase I and II IPsec ISAKMP protocols between the terminalin the visited network and a home agent server which is linked to thecalling authority server (CA) and which located in a home area; making alocation binding update in the terminal using the IPsec securityassociation (SA); sending a request to check the public keycertification to the calling authority server (CA) from the home agentserver; responding from the calling authority server whether prefixallocation is allowed with a prefix and creating a home address for theterminal; discovering and obtaining a home address of the home agentserver by the terminal; making a location binding update by the terminalusing a binding cache from the home agent server; thereby providing anauthentication method for verifying a terminal authenticity by linking adigital signature method with a location binding update method.